Surface real /api/gmaps/key error status on the frontend - #31
Conversation
fetch() never rejects on non-2xx status, so 'r.json()' on a 403 (Forbidden — origin mismatch) or 503 (key not configured) response silently parsed the error body without checking r.ok. The catch block then always logged the same generic 'No Google Maps API key returned' regardless of the real cause, making it impossible to diagnose from the browser console alone. Now checks r.ok/r.status and surfaces the actual error message and HTTP status in both the console error and the on-page banner.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_2684c6af-9cb2-4ed7-93be-971db60e335f) |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
2 participants
Summary
fetch()never rejects on non-2xx responses, sobackend/public/app.js's.then(r => r.json())on a 403 (origin mismatch) or 503 (key not configured) response from/api/gmaps/keysilently parsed the error body without checkingr.ok. Thecatchblock then always logged the same generic"No Google Maps API key returned"message regardless of which of the two real causes was in play — making it impossible to diagnose from the browser console alone (this is exactly what the user hit after rotating their Maps key).Fix
app.jsnow readsr.ok/r.statusalongside the parsed body and surfaces the actual backend error message and HTTP status in both the console error and the on-page banner, e.g.Map unavailable: Forbidden (HTTP 403)vsMap unavailable: Google Maps API key not configured (HTTP 503).Test plan
npm test— 119/119 passing (no test coverage for this static frontend file; verified by reading the diff and cross-checking againstweatherProxyController.js's two error response shapes)Generated by Claude Code
Note
Low Risk
Small change to static frontend error handling for the Maps key fetch; no auth or data-path changes.
Overview
Fixes misleading map load errors when
/api/gmaps/keyreturns non-2xx responses (e.g. 403 origin mismatch or 503 missing key). The bootstrapfetchnow inspectsresponse.okandstatusalongside the JSON body instead of only checking fordata.key.On failure, it throws with the backend
errormessage and HTTP status, andshowMapLoadError/ the console log show that text instead of always blaming a missingGOOGLE_MAPS_API_KEY.Reviewed by Cursor Bugbot for commit e2cfe3b. Configure here.
Summary by cubic
Surface the real error status and message from
/api/gmaps/keyon the frontend so map failures are clear, not generic. We now show the HTTP status and backend message in both the console and the on-page banner.r.okandr.statusbefore using the response; display the backend error and HTTP code in the console and the banner.Written for commit e2cfe3b. Summary will update on new commits.